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Abstract 

Typestate  systems  allow  the  type  of  an  object  to  change  during  its  lifetime  in 
the  computation.  Unlike  standard  type  systems,  they  can  enforce  safety  properties 
that  depend  on  changing  object  states.  We  present  a  new,  generalized  formulation 
of  typestate  that  models  the  typestate  of  an  object  through  membership  in  abstract 
sets.  This  abstract  set  formulation  enables  developers  to  reason  about  cardinalities 
of  sets,  and  in  particular  to  state  and  verify  the  condition  that  certain  sets  are 
empty.  We  support  hierarchical  typestate  classifications  by  specifying  subset  and 
disjointness  properties  over  the  typestate  sets. 

We  present  our  formulation  of  typestate  in  the  context  of  the  Hob  program  spec¬ 
ification  and  verification  framework.  The  Hob  framework  allows  the  combination  of 
typestate  analysis  with  powerful  independently  developed  analyses  such  as  shape 
analyses  or  theorem  proving  techniques.  We  implemented  our  analysis  and  anno¬ 
tated  several  programs  (75-2500  lines  of  code)  with  set  specifications.  Our  imple¬ 
mentation  includes  several  optimizations  that  improve  the  scalability  of  the  analysis 
and  a  novel  loop  invariant  inference  algorithm  that  eliminates  the  need  to  specify 
loop  invariants.  We  present  experimental  data  demonstrating  the  effectiveness  of 
our  techniques. 


1  Introduction 

Typestate  systems  [7,10,12,13,21,37]  allow  the  type  of  an  object  to  change 
during  its  lifetime  in  the  computation.  Unlike  standard  type  systems,  typestate 
systems  can  enforce  safety  properties  that  depend  on  changing  object  states. 


1  This  research  was  supported  by  DARPA  Contract  F33615-00-C-1692,  NSF 
Grant  CCR-0086154,  NSF  Grant  CCR-0073513,  NSF  Grant  CCR-0209075,  and  the 
Singapore-MIT  Alliance. 

2  This  is  a  revised  version  of  the  paper  [26].  The  present  version  contains  a  new 
technique  for  loop  invariant  inference,  and  improves  the  presentation  of  the  system. 


This  report  was  written  in  September  2006. 


This  paper  develops  a  new,  generalized  formulation  of  typestate  systems.  In¬ 
stead  of  associating  a  single  typestate  with  each  object,  our  system  models 
each  typestate  as  an  abstract  set  of  objects.  Objects  may,  of  course,  simul¬ 
taneously  belong  to  multiple  sets.  If  an  object  is  in  a  given  typestate,  it  is  a 
member  of  the  set  that  corresponds  to  that  typestate.  This  formulation  imme¬ 
diately  leads  to  several  generalizations  of  the  standard  typestate  approach.  It 
is  possible  to  relate  typestate  sets  by  specifying  subset  and  disjointness  prop¬ 
erties  over  sets,  which  enables  our  approach  to  support  hierarchical  typestate 
classifications.  Furthermore,  the  use  of  the  boolean  algebra  of  sets  to  reason 
about  set  membership  enables  our  approach  to  reason  about  cardinalities  of 
sets,  and  in  particular  to  state  and  verify  that  certain  sets  are  empty.  Finally, 
a  typestate  in  our  formulation  can  be  formally  related  to  a  potentially  com¬ 
plex  property  of  an  object,  with  the  relationship  between  the  typestate  and 
the  property  verified  using  powerful  independently  developed  analyses  such  as 
shape  analyses  or  theorem  provers. 

We  implemented  the  idea  of  generalized  typestate  in  the  Hob  program  specifi¬ 
cation  and  verification  framework  [24-28].  This  framework  supports  the  divi¬ 
sion  of  the  program  into  instantiable,  separately  analyzable  modules.  Modules 
encapsulate  private  state  and  export  abstract  sets  of  objects  that  support 
abstract  reasoning  about  the  encapsulated  state.  Abstraction  functions  spec¬ 
ify  the  objects  that  participate  in  each  abstract  set,  and  are  defined  using 
unary  predicates  on  the  encapsulated  state.  Modules  also  export  procedures 
that  may  access  the  encapsulated  state  and  therefore  change  the  contents  of 
the  exported  abstract  sets.  Each  module  uses  set  algebra  expressions  involv¬ 
ing  operators  such  as  set  union  or  difference  to  specify  the  preconditions  and 
postconditions  of  exported  procedures.  As  a  result,  the  analysis  of  client  mod¬ 
ules  that  coordinate  the  actions  of  other  modules  can  reason  solely  in  terms 
of  the  exported  abstract  sets  and  avoid  the  complexity  of  reasoning  about  any 
encapsulated  state. 

When  the  encapsulated  state  implements  a  data  structure  (such  as  a  list,  hash 
table,  or  tree),  the  resulting  abstract  sets  characterize  how  objects  participate 
in  that  data  structure.  The  developer  can  then  use  the  abstract  sets  to  spec¬ 
ify  consistency  properties  that  involve  multiple  data  structures  from  different 
modules.  Such  a  property  might  state,  for  example,  that  two  data  structures 
involve  disjoint  objects  or  that  the  objects  in  one  data  structure  are  a  subset 
of  the  objects  in  another.  In  this  way,  our  approach  captures  global  sharing 
patterns  and  characterizes  both  local  and  global  data  structure  consistency. 

The  verification  of  a  program  in  our  system  consists  of  the  application  of 
potentially  different  specialized  analyses  to  verify  1)  the  set  interfaces  of  all 
of  the  modules  in  the  program  and  2)  the  validity  of  the  global  data  struc¬ 
ture  consistency  properties.  The  set  specifications  separate  the  analysis  of  a 
complex  program  into  independent  verification  tasks,  where  each  task  is  veri¬ 
fied  by  an  appropriate  specialized  analysis  plugin  [24] .  Our  approach  therefore 
makes  it  possible,  for  the  first  time,  to  apply  multiple  specialized,  extremely 
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precise,  and  unscalable  analyses  such  as  shape  analysis  [31,34]  or  even  man¬ 
ually  aided  theorem  proving  [38]  to  effectively  verify  sophisticated  typestate 
and  data  structure  consistency  properties  in  sizable  programs. 

Specification  Language.  Our  specification  language  is  the  full  first-order 
theory  of  the  boolean  algebra  of  sets.  In  addition  to  basic  typestate  properties 
expressible  using  quantifier- free  boolean  algebra  expressions,  our  language  can 
state  constant  bounds  on  the  cardinalities  of  sets  of  objects,  such  as  “a  local 
variable  is  not  null”  or  “the  content  of  the  queue  is  nonempty” ,  or  even  “the 
data  structure  contains  at  least  one  and  at  most  ten  objects” .  Because  a  cardi¬ 
nality  constraint  counts  all  objects  that  satisfy  a  given  property,  our  specifica¬ 
tion  language  goes  beyond  standard  typestate  approaches  that  use  per-object 
finite  state  machines.  Our  specification  language  also  supports  quantification 
over  sets.  Universal  set  quantifiers  are  useful  for  stating  parametric  properties; 
existential  set  quantifiers  are  useful  for  information  hiding.  Note  that  quantifi¬ 
cation  over  sets  is  not  directly  expressible  even  in  such  sophisticated  languages 
as  first-order  logic  with  transitive  closure.  Despite  this  expressive  power,  our 
set  specification  language  is  decidable  and  furthermore  extends  naturally  to 
Boolean  Algebra  with  Presburger  Arithmetic  [22, 23] . 

The  Flag  Analysis  Plugin.  The  generalized  typestate  analysis  in  the  Hob 
system  is  implemented  in  the  fl,ag  analysis  plugin ,  which  is  the  focus  of  this 
paper.  The  flag  analysis  plugin  uses  the  values  of  integer  and  boolean  object 
fields  (flags)  to  define  the  meaning  of  abstract  sets.  It  verifies  set  specifications 
by  first  constructing  set  algebra  formulas  whose  validity  implies  the  validity 
of  the  set  specifications,  then  verifying  these  formulas  using  an  off-the-shelf 
decision  procedure  [19]. 

The  flag  analysis  plugin  is  important  for  two  reasons.  First,  flag  field  values 
often  reflect  the  high-level  conceptual  state  of  the  entity  that  an  object  rep¬ 
resents,  and  flag  changes  correspond  to  changes  in  the  conceptual  state  of 
the  entity.  By  using  flags  in  preconditions  of  object  operations,  the  developer 
can  specify  key  object  state  properties  required  for  the  correct  processing  of 
objects  and  the  correct  operation  of  the  program.  Unlike  standard  typestate 
approaches,  our  flag  analysis  plugin  can  enforce  not  only  temporal  operation 
sequencing  constraints,  but  also  the  generalizations  that  our  expressive  set 
specification  language  enables. 

Second,  the  flag  analysis  plugin  can  propagate  constraints  between  abstract 
sets  defined  with  arbitrarily  sophisticated  abstraction  functions  in  external 
modules.  The  plugin  can  therefore  analyze  modules  that,  as  they  coordinate 
the  operation  of  other  modules,  indirectly  manipulate  external  data  structures 
defined  in  those  other  modules.  This  enables  the  flag  analysis  to  perform  the 
intermodule  reasoning  required  to  verify  global  invariants  relating  different 
data  structures,  e.g.  inclusion  and  disjointness  of  data  structures.  Because  the 
flag  plugin  uses  the  boolean  algebra  of  sets  to  internally  represent  its  dataflow 
facts,  it  can  propagate  and  verify  these  constraints  in  a  precise  way. 
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Evaluation.  We  implemented  our  flag  analysis  plugin  in  the  context  of  the 
Hob  system  [27, 28] .  In  addition  to  the  flag  analysis  plugin,  the  Hob  system 
contains  a  shape  analysis  plugin  based  on  Pointer  Assertion  Logic  Tool  [31], 
and  a  theorem  proving  plugin  [38]  that  uses  a  verification-condition  generator 
and  the  Isabelle  interactive  proof  assistant  [32].  We  used  the  flag  analysis 
plugin  to  verify  high-level  properties  in  our  benchmarks;  we  used  the  other 
two  plugins  to  verify  implementations  of  encapsulated  data  structures.  Overall, 
most  of  the  code  was  verified  using  the  scalable  flag  analysis  plugin,  allowing 
the  more  precise  analyses  to  be  focused  on  the  intricacies  of  internal  data 
structure  implementations. 

Our  initial  implementation  of  the  flag  analysis  algorithm  simply  synthesized 
boolean  algebra  formulas  and  used  the  MONA  decision  procedure  [19]  directly 
to  discharge  them.  We  found  that  scalability  problems  with  the  MONA  de¬ 
cision  procedure  prevented  this  initial  approach  from  analyzing  some  of  our 
benchmarks.  We  therefore  implemented  several  formula  simplifications  that 
substantially  improved  the  scalability  of  the  flag  analysis;  we  present  experi¬ 
mental  data  that  show  the  effect  of  our  formula  simplifications. 

Loop  invariant  inference.  Our  flag  analysis  is  based  on  symbolically  com¬ 
puting  the  postconditions  of  statements,  which  makes  it  precise.  A  general 
problem  with  such  an  approach  is  the  handling  of  loops.  Previously,  our  anal¬ 
ysis  used  a  simple  loop  invariant  inference  technique  that  was  often  ineffective 
at  deriving  loop  invariants;  developers  would  typically  be  forced  to  supply  loop 
invariants  explicitly.  Like  procedure  summaries,  invariants  provide  useful  in¬ 
formation  for  code  understanding;  however,  unlike  procedure  summaries,  they 
are  not  essential  for  modular  analysis.  To  eliminate  the  necessity  of  writing 
loop  invariants,  we  have  therefore  developed  a  more  sophisticated  loop  invari¬ 
ant  inference  technique,  which  we  present  in  Section  6.  We  found  that  our  loop 
invariant  inference  technique  was  successful  in  inferring  all  loop  invariants  in 
our  benchmarks. 

2  Example 

In  this  section  we  illustrate  how  Hob  analyzes  a  program  consisting  of  multiple 
modules  and  explain  the  role  of  the  flag  analysis  plugin  in  Hob. 


Fig.  1.  Modules  in  Minesweeper  implementation 
We  use  an  implementation  of  the  popular  Minesweeper  game  as  an  example. 
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impl  module  Board  {  spec  module  Board  { 


format  Cell  { 
isMined  :  bool; 
isExposed  :  bool; 
isMarked  :  bool; 
i,  j  :  int; 
init  :  bool; 

} 

var  init,  peeking,  gameOver  :  bool; 

proc  revealAllUnexposedO  { 
UnexposedList  .openlterO  ; 
bool  b  =  UnexposedList. isLastlter () ; 
while  (!b)  { 

Cell  c  =  UnexposedList. nextlter () ; 
UnexposedList. remove (c) ; 
c. isExposed  =  true; 

ExposedSet . add(c) ; 
b  =  UnexposedList . isLastlter () ; 

} 


Fig.  2.  Implementation  of  Board 


format  Cell; 

specvar  MarkedCells,  MinedCells, 

ExposedCells,  UnexposedCells , 
U  :  Cell  set; 


specvar  init,  peeking,  gameOver  :  bool; 

proc  revealAllUnexposedO 

requires  gameOver  &  init  &  not  peeking 
modifies  ExposedCells,  UnexposedCells 
ensures  card(UnexposedCellsO  =  0; 


Fig.  3.  Specification  of  Board 


abst  module  Board  { 

use  plugin  "flags"; 

U  =  {  x  :  Cell  |  "x.init  =  true"  }; 

MarkedCells  =  U  cap  {  x  :  Cell  I  "x. isMarked  =  true"  }; 
ExposedCells  =  U  cap  {  x  :  Cell  I  "x. isExposed  =  true"  >; 
UnexposedCells  =  U  cap  {  x  :  Cell  I  "x. isExposed  =  false"  }; 
MinedCells  =  U  cap  {  x  :  Cell  I  "x. isMined  =  true"  }; 
predvar  gameOver;  predvar  init;  predvar  peeking; 


Fig.  4.  Abstraction  of  Board 

Figure  1  presents  the  module  diagram  of  our  minesweeper  implementation, 
with  boxes  representing  modules  and  arrows  representing  procedure  calls.3 
Our  minesweeper  implementation  has  several  modules:  a  game  board  module 
(which  represents  the  game  state),  a  controller  module  (which  responds  to 
user  input),  a  view  module  (which  produces  the  game’s  output),  an  exposed 
cell  module  (which  stores  the  exposed  cells  in  an  array),  and  an  unexposed 
cell  module  (which  stores  the  unexposed  cells  in  an  instantiated  linked  list). 

Each  module  in  Hob  consists  of  three  sections:  the  implementation  section,  the 
specification  section,  and  the  abstraction  section.  Our  minesweeper  implemen¬ 
tation  uses  the  standard  model- view-controller  (MVC)  design  pattern  [16];  the 
Board  module  implements  the  model  part  of  the  MVC  pattern.  Figures  2,  3, 
and  4  present  the  three  sections  of  the  Board  module. 

The  implementation  section  contains  the  executable  code  for  each  procedure 
of  the  module,  written  in  a  type-safe  imperative  language  similar  to  Java  or 
ML.  In  this  example  we  examine  the  revealAllUnexposed  procedure,  which 

3  Rill  source  code  for  the  minesweeper  example  and  other  case  studies,  the  inter¬ 
preter,  the  Java  translator,  and  the  Hob  analysis  engine  are  available  at  the  Hob 
homepage,  http://hob.csail.mit.edu.  The  Hob  page  is  served  by  a  custom  web 
server  implemented  in  the  Hob  language. 
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is  called  at  the  end  of  the  game  to  reveal  the  positions  of  all  cells  that  have 
not  been  exposed  so  far.  In  addition  to  procedure  implementations,  the  im¬ 
plementation  section  contains  declarations  of  private  global  variables,  such  as 
the  boolean  variables  gameOver,  init,  and  peeking  in  Figure  2,  and  field  dec¬ 
larations,  such  as  isMined,  isExposed,  and  isMarked.  These  fields  reflect  the 
fact  that  each  Cell  object  may  represent  a  mined,  exposed  or  marked  cell  in 
the  minesweeper  game.  Field  declarations  are  grouped  into  formats.  Multiple 
modules  can  contribute  fields  to  the  same  format,  allowing  encapsulation  at 
the  granularity  of  fields  [25] . 

The  specification  section  contains  the  public  interface  for  the  module,  ex¬ 
pressed  in  terms  of  specification  variables,  including  the  global  set-valued 
variables  MarkedCells,  MinedCells,  ExposedCells,  and  UnexposedCells, 
and  the  global  boolean  variables  in  Figure  3.  The  specification  section  allows 
the  clients  of  the  module  to  reason  about  module  behavior  without  having 
access  to  the  implementation  of  the  module.  The  specification  module  de¬ 
scribes  the  behavior  of  each  procedure  using  procedure  contracts  written  in 
terms  of  the  specification  variables.  For  example,  the  contract  of  procedure 
revealAHUnexposed  indicates  1)  that  the  procedure  may  only  be  called  when 
the  gameOver  variable  is  true,  2)  that  the  only  relevant  specification  variables 
that  are  modified  are  ExposedCells  and  UnexposedCells,  and  3)  that  the  size 
of  the  set  UnexposedCells  at  the  end  of  procedure  execution  is  zero,  that  is, 
the  set  is  empty.  Section  3  describes  our  specification  language  more  detail. 

Finally,  the  abstraction  section  of  the  module  specifies  the  mapping  between 
the  implementation  section  and  the  abstraction  section,  by  defining  each  spec¬ 
ification  variable  in  terms  of  implementation  variables.  For  example,  the  ab¬ 
straction  section  in  Figure  4  defines  the  set  UnexposedCells  as  the  set  of  all 
allocated  objects  whose  init  field  is  true  and  whose  isExposed  field  is  false. 
The  abstraction  section  also  indicates  the  name  of  the  analysis  plugin  used 
to  analyze  the  module;  the  Board  module  uses  the  flag  plugin.  The  defining 
formula  of  each  specification  variable  is  given  in  a  language  specific  to  the  plu¬ 
gin  used  to  analyze  the  module;  see  [38]  for  another  example  of  specification 
variable  definitions. 

Our  system  uses  the  flag  analysis  plugin  to  verify  that  our  implementation 
has  the  following  properties  (among  others): 

•  Unless  the  game  is  over,  the  set  of  mined  cells  is  disjoint  from  the  set  of 
exposed  cells. 

•  The  sets  of  exposed  and  unexposed  cells  are  disjoint. 

•  The  set  of  unexposed  cells  maintained  in  the  Board  module  is  identical  to 
the  set  of  unexposed  cells  maintained  in  the  Unexpo sedList  list. 

•  The  set  of  exposed  cells  maintained  in  the  Board  module  is  identical  to  the 
set  of  exposed  cells  maintained  in  the  ExposedSet  array. 

•  At  the  end  of  the  game,  all  cells  are  revealed;  that  is,  the  set  of  unexposed 
cells  is  empty. 
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spec  module  UnexposedList  { 
format  Cell; 

specvar  Content,  Iter  :  Cell  set; 
invariant  Iter  in  Content; 


proc  remove (n  :  Cell) 
requires  card(n)=l  &  (n  in  Content) 
modifies  Content,  Iter 
ensures  (Content1  =  Content  -  n)  & 
(Iter’  =  Iter  -  n) ; 

proc  openlterO 
requires  card(Iter)  =  0 
modifies  Iter 
ensures  (Iter’  =  Content); 

proc  isLastlterO  returns  e:bool 
ensures  not  e’  <=>  (card(Iter ’)>=  1); 


scope  Model  { 

modules  Board,  ExposedSet,  UnexposedList; 

exports  Board; 

invariant 

(Board. ExposedCells  =  ExposedSet .Content)  & 
(Board. UnexposedCells  =  UnexposedList .Content) 
(Board. init  =>  ExposedList.setlnit)  & 

(Board. peeking  I 

(card (UnexposedList . Iter)  =0)); 


} 


& 


Fig.  5.  Specification  of  the 
UnexposedList  module 


Fig.  6.  Scope  for  Minesweeper  Example 


To  illustrate  our  flag  analysis,  we  discuss  the  analysis  of  the 
revealAHUnexposed  procedure.  The  goal  of  the  analysis  is  to  show 
that  the  implementation  in  Figure  2  conforms  to  the  specification  in 
Figure  3  when  the  specification  variables  are  defined  as  in  Figure  4.  The 
procedure  revealAHUnexposed  invokes  operations  in  the  UnexposedList 
and  ExposedSet  modules,  which  implement  sets  using  linked  lists  and 
arrays  respectively.  Figure  5  shows  a  fragment  of  the  specification  of  the 
UnexposedList  module.  Hob’s  separation  of  modules  into  implementation, 
specification  and  abstractions  sections  enables  analyses  to  examine  only 
the  specifications  of  called  modules.  For  example,  the  analysis  of  the  Board 
module  need  not  handle  the  complexity  of  analyzing  the  implementation 
of  UnexposedList.  It  simply  uses  the  specification  of  remove  in  Figure  5 
to  derive  the  effect  of  a  call  UnexposedList  .remove  (c)  in  Figure  2. 
The  analysis  of  revealAHUnexposed  starts  with  the  full  precondition  of 
revealAHUnexposed.  The  full  precondition  includes  the  explicitly  stated 
requires  clause  in  Figure  3,  as  well  as  the  scope  invariant  in  Figure  6.  A  scope 
in  the  Hob  system  is  a  collection  of  modules,  some  of  which  are  exported, 
along  with  a  list  of  scope  invariants  [25] .  Scope  invariants  are  global  invariants 
that  span  specification  variables  from  multiple  modules;  these  invariants  are 
implicitly  conjoined  to  the  preconditions  and  postconditions  of  all  pul  the 
procedures  declared  in  exported  modules,  including  the  revealAHUnexposed 
procedure  that  we  are  discussing. 


Starting  from  the  precondition,  the  flag  analysis  uses  a  postcondition  se¬ 
mantics  of  statements  to  compute  an  approximation  of  the  transition  re¬ 
lation  between  1)  the  initial  state  of  the  procedure  and  2)  the  state  of 
the  procedure  at  each  program  point.  The  flag  analysis  represents  this  ap¬ 
proximation  as  a  formula  relating  unprimed  variables  and  primed  variables. 
Upon  entry  to  the  procedure,  the  relation  contains  the  precondition,  as  well 
as  the  conjuncts  such  as  UnexposedList .  Iter ;  =  UnexposedList .  Iter 
for  each  variable  relevant  to  the  analysis  of  the  procedure,  indicating 


7 


that  none  of  the  variables  have  changed.  When  analyzing  the  first  state¬ 
ment,  UnexposedList.openlterO ,  the  flag  analysis  checks  that  the  cur¬ 
rent  state  implies  the  precondition  of  openlter,  which  follows  from  the 
clause  not  peeking  from  the  revealAHUnexposed  precondition,  combined 
with  the  scope  invariant.  The  analysis  then  uses  the  specification  of 
openlter  to  derive  a  new  transition  relation  formula  that  implies  Iter’  = 
Content  (and  does  not  contain  the  conjunct  UnexposedList .  Iter  ’  = 

UnexposedList .  Iter).  Subsequent  analysis  derives  properties  that  involve 
local  variables;  for  instance,  b  <=>  card  (UnexposedList .  Iter’ )  >=1  holds 
after  a  call  to  UnexposedList .  isLastlter.  The  analysis  of  the  loop  proceeds 
by  iterating  the  loop  several  times  and  removing  the  conjuncts  that  do  not 
persist  across  all  loop  iterations.  Section  6  describes  our  loop  invariant  infer¬ 
ence  algorithm  in  greater  detail.  Eventually  the  fixpoint  iteration  terminates 
and  the  analysis  verifies  that  the  synthesized  loop  invariant  implies  the  post¬ 
condition,  which  consists  of  1)  the  ensures  clause  and  2)  the  scope  invariant. 

Note  that,  in  the  course  of  its  operation,  our  flag  analysis  verifies  that  the 
invoked  procedures  in  UnexposedList  are  always  used  correctly.  This  usage 
constraint  includes  data  structure  operation  preconditions:  any  element  in¬ 
serted  into  the  list  with  ExposedList .  add(c)  must  not  already  be  in  the  list. 
Furthermore,  our  flag  analysis  propagates  boolean  conditions  reflecting  global 
game  state  information,  such  as  init,  not  peeking  and  gameOver.4  In  the 
rest  of  this  paper  we  describe  the  flag  analysis  of  our  framework  in  more  detail. 

3  Specification  Language 

Figure  7  presents  the  syntax  for  the  specification  section  of  modules  in  our 
language.  This  section  contains  a  list  of  set  definitions  and  procedure  specifi¬ 
cations  and  lists  the  names  of  types  used  in  these  set  definitions  and  proce¬ 
dure  specifications.  Set  declarations  identify  the  module’s  abstract  sets,  while 
boolean  variable  declarations  identify  the  module’s  abstract  boolean  variables. 
Each  procedure  specification  contains  a  requires,  modifies,  and  ensures 
clause.  The  requires  clause  identifies  the  precondition  that  the  procedure 
requires  to  execute  correctly;  the  ensures  clauses  identifies  the  postcondition 
that  the  procedure  ensures  when  called  in  program  states  that  satisfy  the 
requires  condition.  The  modifies  clause  identifies  sets  whose  elements  may 
change  as  a  result  of  executing  the  procedure.  For  the  purposes  of  this  pa¬ 
per,  modifies  clauses  can  be  viewed  as  a  special  syntax  for  a  frame-condition 
conjunct  in  the  ensures  clause.  The  variables  in  the  ensures  clause  can  refer 
to  both  the  initial  (unprimed  variables)  and  final  (primed  variables)  states  of 
the  procedure.  Both  requires  and  ensures  clauses  use  arbitrary  first-order 
boolean  algebra  formulas  B  extended  with  cardinality  constraints.  A  free  vari- 

4  The  Hob  framework  supports  an  additional  default  construct  that  allows  the 
developer  to  specify  conjuncts  such  as  init  and  not  peeking  as  default  values  that 
apply  to  a  set  of  procedures  given  by  some  crosscut  expression,  so  these  conjuncts 
need  not  be  repeated  for  every  procedure  [25] . 
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M  ::=  spec  module  m  {(type  t)*( set  S)*(predvar  b)*P*} 

P  ::=  proc  pn(jp\  :  ti,...,pn  :  tn) [returns  r:  t] 

[requires  B]  [modifies S'*]  ensures  B 
B  ::=  SE i  =  SE2  j  SBj  C  SE2  |  card(S£)=fe 

|  “iB  |  3S.B  |  WS.B 

SE  ::=  0  \  p  \  [m.\  S  j  [m.]  S' 

|  si?!  u  se2  |  Si?!  n  se2  \  se%  \  se2 

Fig.  7.  Syntax  of  the  Module  Specification  Language 

M  ::=  abst  module  m  {D*  P*} 

D  id=Dr; 

Dr  ::=  Dr  U  Dr  \  Dr  n  Dr  |  id  |  {x  :  T  \  x.f=c} 

P  predvar  p; 

Fig.  8.  Syntax  of  the  Flag  Abstraction  Language 

able  of  any  formula  appearing  in  a  module  specification  denotes  an  abstract 
set  or  boolean  variable  declared  in  that  specification;  it  is  an  error  if  no  such 
set  or  boolean  variable  has  been  declared.  The  expressive  power  of  such  for¬ 
mulas  is  the  first-order  theory  of  boolean  algebras,  which  is  decidable  [20, 30] . 
The  decidability  of  the  specification  language  ensures  that  analysis  plugins 
can  precisely  propagate  the  specified  relations  between  the  abstract  sets. 

4  Overview  of  Flag  Analysis 

Our  flag  analysis  verifies  that  modules  implement  set  specifications  in  which 
integer  or  boolean  flags  indicate  abstract  set  membership.  The  developer  spec¬ 
ifies  (using  the  flag  abstraction  language)  the  correspondence  between  con¬ 
crete  flag  values  and  abstract  sets  from  the  specification,  as  well  as  the  corre¬ 
spondence  between  the  concrete  and  the  abstract  boolean  variables.  Figure  8 
presents  the  syntax  for  our  flag  abstraction  modules.  This  abstraction  lan¬ 
guage  defines  abstract  sets  in  two  ways:  (1)  directly,  by  stating  a  base  set;  or 
(2)  indirectly,  as  a  set-algebraic  combination  of  sets.  Base  sets  have  the  form 
B  —  {x  \T  |  x.f—c}  and  include  precisely  the  objects  of  type  T  whose  held  f 
has  value  c,  where  c  is  an  integer  or  boolean  constant;  the  analysis  converts 
mutations  of  the  held  f  into  set-algebraic  modifications  of  the  set  B.  Derived, 
sets  are  dehned  as  set  algebraic  combinations  of  other  sets;  the  hag  analysis 
handles  derived  sets  by  conjoining  the  definitions  of  derived  sets  (in  terms  of 
base  sets)  to  each  verification  condition  and  tracking  the  contents  of  the  base 
sets.  Derived  sets  may  use  named  base  sets  in  their  definitions;  additionally, 
they  may  use  anonymous  sets  given  by  set  comprehensions.  In  that  case,  the 
hag  analysis  assigns  internal  names  to  anonymous  sets  and  tracks  their  values 
to  compute  the  values  of  derived  sets. 

Operation  of  the  Analysis  Algorithm.  The  hag  analysis  verifies  a  module 
M  by  verifying  each  procedure  of  M.  To  verify  a  procedure,  the  analysis 
performs  abstract  interpretation  [5]  with  analysis  domain  elements  represented 
by  formulas.  Our  analysis  associates  quantified  set  algebra  formulas  B  to  each 
program  point.  A  formula  B  has  two  collections  of  set  variables:  unprimed  set 
variables  S  denoting  initial  values  of  sets  at  the  entry  point  of  the  procedure, 
and  primed  set  variables  S'  denoting  the  values  of  these  sets  at  the  current 
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program  point.  B  may  also  contain  unprimed  and  primed  boolean  variables 
b  and  //  representing  the  pre-  and  post-values  of  local  and  global  boolean 
variables.  The  definitions  in  the  abstraction  sections  of  the  module  provide  the 
interpretations  of  these  variables.  The  use  of  primed  and  unprimed  variables 
allows  our  analysis  to  represent,  for  each  program  point  p,  a  binary  relation 
on  states  that  overapproximates  the  reachability  relation  between  procedure 
entry  and  p  [6, 17, 35]. 

In  addition  to  the  abstract  sets  from  the  specification,  the  analysis  also  gen¬ 
erates  a  set  for  each  (object-typed)  local  variable.  This  set  is  either  empty, 
indicating  a  null  reference,  or  has  cardinality  one  and  contains  the  object 
to  which  the  local  variable  refers.  The  formulas  that  the  analysis  manipulates 
therefore  support  the  disambiguation  of  local  variable  and  object  held  accesses 
at  the  granularity  of  the  sets  in  the  analysis;  other  analyses  often  rely  on  a 
separate  pointer  analysis  to  provide  this  information. 

The  initial  dataflow  fact  at  the  start  of  a  procedure  is  the  precondition  for  that 
procedure,  transformed  into  a  relation  by  conjoining  S'  —  S  for  all  relevant 
sets.  At  merge  points,  the  analysis  uses  disjunction  to  combine  set  algebra  for¬ 
mulas.  The  analysis  allows  the  developer  to  provide  loop  invariants  directly. 
If  an  invariant  is  not  supplied,  the  analysis  infers  it  using  the  algorithm  in 
Section  6.  After  running  the  dataflow  analysis,  our  analysis  checks  that  the 
procedure  conforms  to  its  specification  by  checking  that  the  derived  postcon¬ 
dition  (which  includes  the  ensures  clause  and  any  required  invariants  and 
defaults  [25])  holds  at  all  exit  points  of  the  procedure.  In  particular,  the  flag 
analysis  checks  that  for  each  exit  point  e,  the  computed  formula  Be  implies 
the  procedure’s  postcondition. 

Computing  Postconditions.  The  transfer  functions  in  the  dataflow  analysis 
update  set  algebra  formulas  to  reflect  the  effect  of  each  statement.  Recall  that 
the  dataflow  facts  for  the  flag  analysis  are  set  algebra  formulas  B  denoting 
a  relation  between  the  state  at  procedure  entry  and  the  state  at  the  current 
program  point.  Let  Bs  be  the  set  algebra  formula  describing  the  effect  of 
statement  s.  The  postcondition  BoBs  is  the  result  of  symbolically  composing 
the  relations  defined  by  the  formulas  B  and  Bs.  Conceptually,  postcondition 
computation  updates  B  with  the  effect  of  Bs.  We  compute  BoBsby  applying 
equivalence-preserving  simplifications  to  the  formula 


3Sj,  ...,Sn.  B[S[  i  *  Si]  A  Bs[Si  i  *  Si] 

Our  flag  analysis  handles  each  statement  in  the  implementation  language  by 
providing  appropriate  transfer  functions  for  these  statements.  The  generic 
transfer  function  is  a  relation  of  the  form  [st](5)  =  £>  o  jF(st),  where  JF(st) 
is  the  formula  symbolically  representing  the  transition  relation  for  the  state¬ 
ment  st  expressed  in  terms  of  abstract  sets.  The  transition  relations  for  the 
statements  in  our  implementation  language  are  in  Appendix  A. 
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Verifying  Implication  of  Dataflow  Facts.  A  compositional  program 
analysis  needs  to  verify  implication  of  constraints  as  part  of  its  operation.  Our 
flag  analysis  verifies  implication  when  it  encounters  an  assertion,  procedure 
call,  or  procedure  postcondition.  In  these  situations,  the  analysis  generates  a 
formula  of  the  form  B  A  where  B  is  the  current  dataflow  fact  and  A  is  the 
claim  to  be  verified. 5  The  implication  to  be  verified,  B  A,  is  a  formula  in 
the  boolean  algebra  of  sets.  We  use  the  MONA  decision  procedure  to  check 
its  validity  [18],  along  with  the  transformations  described  in  Section  5. 

5  Boolean  Algebra  Formula  Transformations 

In  our  experience,  applying  several  formula  transformations  drastically  re¬ 
duced  the  size  of  the  formulas  emitted  by  the  flag  analysis,  as  well  as  the 
time  needed  to  determine  their  validity  using  an  external  decision  procedure; 
in  fact,  some  benchmarks  could  only  be  verified  with  the  formula  transfor¬ 
mations  enabled.  This  section  describes  the  transformations  we  found  to  be 
useful.  Section  8  presents  our  measurements  of  the  improvements  obtained 
from  applying  these  transformations. 

Smart  Constructors.  The  constructors  for  creating  boolean  algebra  for¬ 
mulas  apply  peephole  transformations  as  they  create  the  formulas.  Constant 
folding  is  the  simplest  peephole  transformation:  for  instance,  attempting  to 
create  B  A  true  gives  the  formula  B.  Our  constructors  fold  constants  in  im¬ 
plications,  conjunctions,  disjunctions,  and  negations.  Similarly,  attempting  to 
quantify  over  unused  variables  causes  the  quantifier  to  be  dropped:  3 x.F  is 
created  as  just  F  when  x  does  not  occur  free  within  F.  Most  interestingly,  we 
factor  common  conjuncts  out  of  disjunctions:  (A  AS)  V  (A  AC)  is  represented 
as  A  A  (B  VC).  Conjunct  factoring  greatly  reduces  the  size  of  formulas  tracked 
after  control-flow  merges,  since  most  conjuncts  are  shared  on  both  control-flow 
branches.  The  effects  of  this  transformations  appear  similar  to  the  effects  of 
SSA  form  conversion  in  weakest  precondition  computation  [15,29]. 

Basic  Quantifier  Elimination.  We  symbolically  compute  the  composi¬ 
tion  of  statement  relations  while  computing  postconditions  by  existentially 
quantifying  over  all  state  variables.  However,  most  relations  corresponding  to 
statements  modify  only  a  small  part  of  the  state  and  contain  the  frame  condi¬ 
tion  that  indicates  that  the  rest  of  the  state  is  preserved.  The  result  of  relation 
composition  can  therefore  often  be  written  in  the  form  3x.x  =  x\  AF(x),  which 
is  equivalent  to  F(x i).  In  this  way  we  reduce  both  the  number  of  conjuncts 
and  the  number  of  quantifiers.  Moreover,  this  transformation  can  reduce  some 
conjuncts  to  the  form  t  =  t  for  some  Boolean  algebra  term  t.  which  is  a  true 
conjunct  that  is  eliminated  by  further  simplifications. 

5  Note  that  B  may  be  unsatisfiable;  this  often  indicates  a  problem  with  the  pro¬ 
gram’s  specification.  The  flag  analysis  can,  optionally,  check  whether  B  is  unsatis¬ 
fiable  and  emit  a  warning  if  it  is.  This  check  enabled  us  to  improve  the  quality  of 
our  specifications  by  identifying  errors  in  specifications. 
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It  is  instructive  to  compare  our  technique  to  weakest  precondition  computation 
[15]  and  forward  symbolic  execution  [4].  These  techniques  are  optimized  for 
the  common  case  of  assignment  statements  and  perform  relation  composition 
and  quantifier  elimination  in  one  step.  Our  technique  achieves  the  same  result, 
but  is  methodologically  simpler  and  applies  more  generally.  In  particular,  our 
technique  can  take  advantage  of  equalities  in  transfer  functions  that  are  not  a 
result  of  analyzing  assignment  statements,  but  are  given  by  explicit  formulas 
in  ensures  clauses  of  procedure  specifications.  Such  transfer  functions  may 
specify  more  general  equalities  such  as  /I  —  A'  U  x  A  B'  —  B  U  x  which  do 
not  reduce  to  simple  backward  or  forward  substitution. 

Leveraging  Quantifier  Elimination  in  Implications  We  rewrite  \/x.f 
g  as  -i(E \x.f  A  -> g).  This  greatly  increases  the  applicability  of  the  quantifier- 
elimination  optimization  described  above. 

Quantifier  Nesting.  We  have  experimentally  observed  that  the  MONA 
decision  procedure  works  substantially  faster  when  each  quantifier  is  applied 
to  the  smallest  scope  possible.  We  have  therefore  implemented  a  quantifier 
nesting  step  that  reduces  the  scope  of  each  quantifier  to  the  smallest  possible 
subformula  that  contains  all  free  variables  in  the  scope  of  the  quantifier.  For 
example,  our  transformation  replaces  the  formula  \/x.  Vy.  (/(r)  =>-  g(y))  with 
(3x.  f(x))  =>  (Vy.  g(y)). 

To  take  maximal  advantage  of  our  transformations,  we  simplify  formulas  after 
relation  composition  and  before  invoking  the  decision  procedure.  Our  global 
simplification  step  rebuilds  formulas  bottom-up  and  applies  simplifications  to 
each  subformula. 

6  Loop  Invariant  Synthesis 

In  this  section,  we  summarize  how  our  flag  analysis  plugin  handles  loops.  The 
plugin  can  either  verify  developer-provided  loop  invariants  or  synthesize  loop 
invariants  from  the  program  source  code  and  specifications. 

Explicit  Loop  Invariants.  If  the  developer  provides  an  explicit  loop  in¬ 
variant,  the  plugin  verifies  that  the  loop  invariant:  1)  holds  on  entry  to  the 
loop;  and  2)  is  preserved  by  the  loop  body.  At  the  exit  of  the  loop,  the  loop 
invariant  conjoined  with  the  loop  exit  condition  characterizes  the  post-loop 
program  state. 

Our  loop  invariant  verification  algorithm  uses  information  from  the  loop’s  con¬ 
text  to  automatically  augment  the  explicit  loop  invariant  with  properties  that 
are  known  to  be  invariant  over  the  loop.  In  particular,  the  loop’s  containing 
procedure  has  a  requires  clause,  which  states  the  procedure  precondition. 
This  clause  involves  only  the  initial  values  of  sets  at  the  begining  of  the  proce¬ 
dure  (unprimed  set  variables),  and  therefore  holds  throughout  the  procedure 
execution,  including  within  the  loop  body.  We  also  use  the  containing  pro- 
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Infer-Loop-Invariant(/o  ,  loop-condition ,  loop-body ,  max-iterations) 

1 

2  f^fo 

3  /'  «•  Compute-Postcondition(/  A  loop-condition,  loop-body) 

4  while  £  <  max-iterations  and  f'&f 

5  do  /  <—  Get-Implied-Conjuncts(/,  /',  0)  A  Get-Implied-Conjuncts(/',  /,  0) 

6  /'  r~-  Compute-Postcondition(/  A  loop-condition,  loop-body) 

7  i^i+1 

8  if  i  >  max-iterations 

9  then  while 

10  do  /  <—  Get-Implied-Conjuncts(/,  /',[]) 

11  /'  '■  ComputeaPostcondition(/  A  loop- condition,  loop-body) 

12  return  / 

GeT-IMPLIED-CONJUNCTS(/i,  /2,  [xo,  .  .  .  ,  Xn}) 

1  result^-  True 

2  foreach  c  in  Conjuncts(/i) 

3  if  /2  =>  -zo - -.xn.(: 

4  then  result  <—  c  A  result 

5  else  if  c  has  the  form  3x.e 

6  then  result  <—  HANDLE-ExiSTENTlAL(e,  /2,  [xo, . . . ,  xn,  x])  A  result 

7  return  result 

Handle- Existential^,  /,  [xo, . . . ,  x„]) 

1  g  <—  GET-lMPLIED-CONJUNCTS(e,  f,  [xo,  .  .  .  ,  X„]) 

2  if  /=^3xo,...,xn-g 

3  then  return  3 xn.g 

4  g  *—  True 

5  foreach  c  in  CoNJUNCTs(e) 

6  if  c  does  not  contain  xn 

7  then  g  «—  cAg 

8  return  GET-lMPLlED-CONJUNCTS(g,  /,  [xo, . . . , xn_i]) 

Fig.  9.  Pseudo-code  for  Loop  Invariant  Inference  Algorithm. 

cedure’s  implementation,  as  well  as  its  modifies  clause,  to  identify  all  non- 
modified  sets,  and  construct  a  conjunct  which  states  that  these  non- modified 
sets  are  preserved  by  the  loop  6 .  We  then  conjoin  both  the  original  procedure 
precondition  and  clauses  guaranteeing  the  preservation  of  non-modified  sets 
to  all  explicit  loop  invariants.  Developers  therefore  need  not  provide  these  two 
pieces  of  redundant  information,  which  helps  to  make  explicit  invariants  more 
concise  and  easier  to  understand. 

Inferred  Loop  Invariants.  If  the  developer  does  not  provide  an  explicit 
loop  invariant,  the  flag  analysis  automatically  synthesizes  one.  The  synthesis 
starts  with  the  formula  characterizing  the  transition  relation  at  the  entry  of 
the  procedure  and  weakens  the  formula  by  iterating  the  analysis  of  the  loop 
until  it  reaches  a  fixpoint.  Figure  9  presents  pseudocode  for  the  algorithm. 
In  the  remainder  of  this  section  we  present  an  example  of  the  algorithm  in 
action,  discuss  some  properties  of  the  algorithm,  and  present  our  experience 
with  the  algorithm  applied  to  our  set  of  benchmarks. 


Example.  Figure  10  presents  procedure  clear,  which  iterates  through  a  set, 


6  Using  the  procedure’s  modifies  clause  alone  results  in  an  overly-conservative 
estimate  of  modified  private  sets  in  the  presence  of  scopes  [25],  because  scope- 
public  procedures  do  not  declare  modifications  of  scope-private  sets.  Our  use  of  the 
modifies  clause,  on  the  other  hand,  allows  the  developer  to  state  more  detailed  in¬ 
formation  about  public  sets  than  our  modified-set  inference  algorithm  could  deduce. 
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specvar  Content  :  Element  set; 


proc  clear ()  //  specification 

requires  true 
modifies  Content 
ensures  card (Content’)  =  0; 

proc  clearO  {  //  implementation 

pre:  bool  e;  e  =  isEmptyO; 
head:  while  (!e)  { 
body:  Entry  q  =  removeFirstO  ; 

e  =  isEmptyO; 

} 

post :  return ; 


proc  isEmptyO  returns  b  :  bool 

ensures  not  b’  <=>  card(Content)>=l 

proc  removeFirstO  returns  e  :  Element 
requires  card(Content)>0 
modifies  Content 

ensures  (card(e’)=l)  &  (e’  in  Content)  & 
(Content ’  =  Content  -  e ’ ) ; 


Fig.  10.  Procedure  containing  a  loop.  Fig.  11.  Procedures  called  within  the  loop. 

removing  each  element  until  the  set  is  empty.  We  use  this  procedure  to  illus¬ 
trate  our  loop  inference  technique.  In  procedure  clear,  each  execution  of  the 
loop  body  removes  an  element  from  the  Content  set.  Because  the  precondition 
of  procedure  removeFirst  must  hold,  the  loop  body  cannot  execute  success¬ 
fully  unless  the  Content  set  is  non-empty,  i.e.  card  (Content  ’ )  >=  1.  The 
postcondition  of  the  procedure  is  card  (Content ’ )  =  0.  A  valid  loop  invariant 
must  ensure  that  executing  the  loop  body  in  a  state  satisfying  the  invariant  1) 
does  not  violate  the  precondition  of  removeFirst,  and  2)  leads  to  a  state  that 
satisfies  the  loop  invariant.  A  valid  loop  invariant  must  also  ensure  that  upon 
termination  of  the  loop,  the  postcondition  of  clear  holds.  One  possible  loop 
invariant  that  satisfies  these  criteria  is  Ip  :  e'  card(Content;)  =  0.  Since  e! 
is  always  false  at  the  top  of  the  loop  body,  Ip  expresses  the  condition  that  the 
set  is  non-empty,  thereby  guaranteeing  that  the  loop  body  can  execute  cor¬ 
rectly;  and  since  e!  is  always  true  when  the  loop  exits,  Ip  implies  that  the  set 
is  empty  at  the  end  of  the  procedure,  satisfying  the  procedure  postcondition. 


Our  analysis  plugin  analyzes  the  clearO  procedure  by  starting  with  the  pro¬ 
cedure  precondition  (in  this  case,  true)  and  successively  computing  an  approx¬ 
imation  of  the  strongest  postcondition  over  the  statements  in  the  procedure. 
Eventually,  the  analysis  reaches  head,  the  while  ()  statement  containing  the 
loop,  with  the  intermediate  analysis  result  /.  By  construction,  /  holds  for  all 
reachable  states  at  program  counter  head  that  the  analysis  has  explored  up 
to  this  point.  In  our  example,  /  is  the  formula: 

/  =  (3e3-  -163)  A  q'  =  0  A  (e'  -icard (Content ’)  >  1)  A  Content  =  Content’ 

The  formula  /  states  that:  1)  at  some  intermediate  stage,  the  variable  e  was 
false  (in  this  case,  e  was  initially  false);  2)  the  variable  q  points  to  null;  3)  e’ 
is  true  iff  the  Content  set  is  nonempty;  and  4)  the  Content  set  is  unchanged 
from  its  value  on  entry  to  the  procedure. 


Our  inference  algorithm  next  strengthens  /  by  conjoining  the  loop  condition, 
producing  a  formula  /0  which  holds  at  the  start  of  the  loop  at  the  label  body 
after  zero  loop  iterations.  For  our  example,  /0  is  /  A  -us': 

/o  =  (3e3-  -C3)  A  q'  =  0  A  (e'  -icard (Content  ’)  >  1)  A  Content  =  Content  ’  A  -1 e ' 

Since  any  loop  invariant  /  must  hold  for  all  such  states,  it  must  be  the  case 
that  /o  I.  However,  /0  is  unlikely  to  be  the  desired  loop  invariant,  since  it 
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does  not  take  into  account  the  effect  of  the  loop  body.  We  therefore  compute 
the  strongest  postcondition  over  the  loop  body,  starting  with  /0  at  the  top  of 
the  loop  body,  to  obtain  f'y  The  formula  /q  holds  for  the  set  of  states  that 
are  reachable  at  the  loop  entry  after  executing  exactly  one  loop  iteration.  Any 
acceptable  loop  invariant  /  must  satisfy  the  constraints  /()  1  and  /g  =>-  /. 

For  our  example: 

/o  =  (3e3.  -163)  A  (e'  4A  -icard (Content ’)  >  1) 

A  (Bes.  -’C.r)  A  (e5  AA  card(Content)  =  1)) 

A  Content  *•  =  Content  \  q'  A  card (q')  =  1  A  q'  G  Content  A  e! 

The  formula  /g  states  that  the  set  Content J  is  equal  to  the  set  Content  minus 
q’ .  which  points  to  an  object  in  the  heap  (since  card (q')  —  1).  The  formula 
/g  also  states  that  at  some  previous  program  state,  the  variable  e  was  true  iff 
the  set  Content  had  cardinality  1.  (Note  that  e5  was  formerly  e!  at  the  top  of 
the  loop;  the  composition  operation  renames  e!  to  the  existentially  quantified 
e5.)  Finally,  /j  states  that  at  some  previous  program  state,  the  variable  e  was 
false,  and  that  at  the  present  state,  e  is  true  iff  the  Content  ’  set  is  empty; 
note  that  these  final  two  conjuncts  are  common  to  /o  and  /g. 

Building  Potential  Invariants.  The  formula  /0  summarizes  the  program 
state  after  zero  iterations  of  the  loop  body;  /q  summarizes  the  state  after 
one  iteration.  Our  goal  is  to  produce  a  logical  formula  which  holds  after  an 
arbitrary  number  of  loop  iterations;  we  can  start  by  producing  a  formula  which 
holds  after  either  zero  or  one  loop  iterations.  We  take  conjuncts  from  /0  which 
are  implied  by  /o,  as  well  as  conjuncts  from  /q  which  are  implied  by  /().  Any 
such  conjuncts  will  then  hold  after  both  zero  and  one  iterations  of  the  loop 
body.  We  conjoin  these  conjuncts  to  produce  the  formula  /j: 

fi  =  (3e3.  -163)  A  (e'  4A  -icard(Content’)  >  1) 

A  Content  ’  =  Content  \  <(  A  q'  €  Content 

In  formula  fi,  we  dropped  the  intermediate  state  e§  and  the  constraint 
card (q')  =  1.  The  intermediate  state  e5  was  dropped  because  it  does  not  ex¬ 
ist  after  zero  iterations  of  the  loop.  The  cardinality  constraint  was  dropped 
because  q'  is  the  empty  set  in  /0  and  known  to  be  nonempty  in  /j.  Dropping 
the  cardinality  constraint  allows  q'  to  contain  an  arbitrary  number  of  heap 
objects;  it  is  no  longer  required  to  point  to  a  single  location  in  the  heap. 

Our  technique  then  checks  whether  f\  is  a  loop  invariant,  using  the  technique 
described  above  for  verifying  explicit  loop  invariants.  In  our  example,  fi  is  not 
a  loop  invariant:  it  contains  the  conjunct  Content ;  =  Content  \  q' .  where  q' 
is  a  free  variable;  that  is,  in  all  iterations  of  the  loop,  Content J  is  equal  to 
Content  minus  q'.  for  all  values  of  q1  (which  is  also  constrained  to  be  a  subset 
of  Content).  While  this  conjunct  holds  for  the  zeroth  and  first  iterations  of 
the  loop,  it  does  not  hold  for  all  iterations  of  the  loop.  Therefore,  we  iterate 
again,  computing  f[ .  the  strongest  postcondition  of  fi  over  the  loop  body.  We 
combine  conjuncts  from  fi  which  are  implied  by  f[  with  conjuncts  from  f[ 
which  are  implied  by  /j,  yielding  the  next  estimate  /2. 
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The  formula  /2  summarizes  the  program  state  after  zero,  one  and  two  iter¬ 
ations.  It  contains  the  clause  Content J  =  Content  \  q8  \  q' .  Because  q8  is 
existentially-quantified  (rather  than  free),  and  because  q8  does  not  carry  any 
cardinality  constraints,  the  set  q8  can  be  interpreted  to  represent  the  differ¬ 
ence  between  the  initial  Content  set  and  the  intermediate  Content ;  set  after 
any  number  of  loop  iterations.  The  analysis  tests  /2  and  finds  that  it  is  a  loop 
invariant. 

f[  =  3eg.  (— ieg  A  3q8.  (. q8  G  Content  Ag'e  Content  \  q8 
A  Content  ’  =  Content  \  q8  \  qr) 

A  (— ieg  GA  card(Content  \  q8)  =  1)) 

A  (  ieg.  Afe)  A  card(q’)  =  1  A  (e'  -icard(Content  ’)  >  1) 

fi  =  3q8.  (q8  G  Content  A  q1  G  Content  \  q8 

A  Content  ’  =  Content  \q8\  (/) 

A  (3e3.  -163)  A  qf  G  Content  A  (e'  AA  -ncard(Content’)  >  1) 

Existential  Quantifiers.  In  our  exposition  so  far,  we  have  ignored  the 
internal  structure  of  the  conjuncts  in  our  formulas,  and  treated  each  top-level 
conjunct  as  an  atomic  unit.  However,  we  found  it  necessary  in  practice  to 
decompose  top-level  conjuncts,  retaining  only  the  parts  of  the  conjunct  which 
are  true.  In  particular,  our  algorithm  is  able  to  infer  stronger  invariants  by 
examining  the  internal  structure  of  existentially  quantified  clauses,  rather  than 
dropping  the  entire  clause.  For  instance,  in  the  formula  above,  if  Cj  is  of  the 
form  Be.  A  <4,  then  we  drop  sub-conjuncts  cJk  that  are  not  implied  by  f[. 
Note,  however,  that  even  if  some  set  of  sub-conjuncts  K  such  that  c?k  G  K 
are  individually  implied  by  //,  it  does  not  necessarily  follow  that  f[  =>  [\K\ 
in  the  presence  of  existential  quantifiers,  two  sub-conjuncts  may  conspire  to 
contradict  the  antecedent.  If  we  do  construct  such  a  K  which  fails  to  imply 
//,  then  we  drop  those  conjuncts  of  K  that  mention  e  and  try  again. 

Comparing  our  inferred  loop  invariant  /2  with  the  invariant  Ip,  we  can  observe 
that  fi  has  a  number  of  extraneous  clauses  (e.g.  q'  G  Content  A  (3e3.  -163), 
and  also  the  clause  containing  q8)  which  are  not  required  to  verify  the  loop  or 
the  procedure  in  general.  We  have  found  no  simple  way  to  produce  automat¬ 
ically  produce  smaller  invariants.  One  possible  heuristic  is  to  eliminate  those 
conjuncts  from  an  inferred  loop  invariant  which  are  not  required  for  the  anal¬ 
ysis  of  the  loop  body  to  go  through.  In  our  experience,  this  strategy  generates 
invariants  that  are  sound,  but  too  weak  to  prove  the  postconditions  of  some 
procedures,  so  we  do  not  apply  it. 

Enforcing  Termination.  As  presented  above,  our  algorithm  for  generating 
and  checking  trial  loop  invariants  is  not  guaranteed  to  terminate;  we  can 
construct  contrived  examples  on  which  our  algorithm  does  not  terminate.  In 
practice,  we  are  able  to  infer  all  loop  invariants  in  our  example  programs  in 
at  most  three  iterations. 

A  small  change  to  the  algorithm  presented  above  ensures  termination  in  all 
cases  where  it  is  possible  to  construct  a  loop  invariant.  We  limit  the  number  of 
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iterations  that  the  original  algorithm  may  execute.  Once  the  limit  is  reached, 
the  algorithm  subsequently  drops  any  non-preserved  conjuncts  and  does  not 
introduce  any  new  ones;  that  is, 

fi+l  =  /\{cj  I  fi  '  cj}- 

3 

This  phase  is  guaranteed  to  terminate  because  it  operates  on  a  finite  number 
of  conjuncts;  no  new  conjuncts  are  added.  If  no  conjuncts  are  dropped  in  a 
given  iteration,  then  the  algorithm  has  found  a  loop  invariant  and  terminates. 
Otherwise,  the  size  of  the  formula  strictly  decreases  at  each  step. 

Our  algorithm,  as  amended,  is  guaranteed  to  never  loop  with  an  infinite  se¬ 
quence  of  potential  invariants  that  are  too  strong.  On  the  other  hand,  we  can 
construct  an  example  where  our  algorithm  produces  an  invariant  that  is  not 
strong  enough  for  verifying  the  loop  body.  If  a  loop  invariant  exists,  the  de¬ 
veloper  can  provide  a  hint  to  the  inference  algorithm  by  inserting  the  pair  of 
statements  assert  C;  assume  C;  inside  the  loop  body. 

Experience  with  Loop  Invariants.  We  applied  our  loop  invariant  infer¬ 
ence  algorithm  to  our  suite  of  benchmarks,  which  includes  an  HTTP  server, 
a  minesweeper  implementation,  and  various  small  programs  (see  Section  8). 
Our  inference  algorithm  successfully  inferred  all  15  invariants  in  our  bench¬ 
mark  programs.  In  a  previous  version  of  our  system  [26],  we  used  a  simpler 
technique  for  loop  invariant  inference.  The  narrow  applicability  of  our  previous 
technique  required  us  to  manually  supply  loop  invariants  for  most  loops  in  our 
example  programs.  Because  the  manually  written  loop  invariants  were  avail- 
air  le  to  us,  we  were  able  to  compare  the  developer-supplied  loop  invariants  with 
the  automatically  inferred  loop  invariants.  In  all  cases,  the  developer-supplied 
invariants  are  simpler  than  the  inferred  loop  invariants,  and  the  developer- 
supplied  invariants  implied  the  inferred  loop  invariants.  The  main  sources  of 
complexity  in  the  inferred  loop  invariant  are  1)  the  preservation  of  (an  ap¬ 
proximation  of  the)  strongest  postcondition  throughout  the  loop,  including 
set  equalities  between  primed  and  unprimed  sets;  and  2)  the  introduction  of 
existential  quantifiers,  as  discussed  above. 

Discussion.  We  were  surprised  to  discover  that  our  simple  loop  invari¬ 
ant  inference  technique  was  able  to  infer  all  of  the  invariants  in  our  example 
programs.  Three  properties  of  the  Hob  system  seem  to  contribute  to  the  feasi¬ 
bility  of  inferring  loop  invariants.  In  general,  it  seems  that  loop  invariants  are 
much  easier  to  infer  when  the  specification  language  is  based  on  sets  (contrast 
this  to  the  JML  specification  language,  which  allows  full  Java  expressions  as 
specifications).  The  set  specification  language  contributes  to  rich  but  focussed 
specifications  for  invoked  procedures,  which  the  loop  inference  algorithm  can 
productively  use  to  build  its  loop  invariant,  as  we  can  observe  in  our  example: 
the  emptiness  constraint  on  the  Content  set  is  the  crucial  ingredient  in  con¬ 
structing  the  right  invariant.  Furthermore,  the  fact  that  formulas  in  our  flag 
analysis  are  composed  of  a  set  of  conjuncts  (in  part  due  to  the  manipulations 
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described  in  Section  5)  allows  the  loop  invariant  inference  algorithm  to  drop 
some  of  the  conjuncts  as  needed.  Our  experience  reinforces  our  belief  that  a 
set-based  specification  language  can  give  a  valuable,  high-level  description  of 
program  behaviour,  making  program  understanding  easier  for  both  program¬ 
mers  and  programs. 

7  Other  Plugins 

In  addition  to  the  flag  analysis,  we  implemented  a  shape  analysis  plugin  and  a 
theorem  proving  plugin.  These  two  plugins  enable  the  Hob  system  to  analyze 
complex  properties  of  encapsulated  data  structures.  To  see  the  importance  of 
these  two  plugins,  note  that  the  flag  analysis  captures  the  sharing  of  objects  at 
the  granularity  of  data  structures  represented  as  sets.  This  greatly  simplifies 
and  improves  the  scalability  of  the  flag  plugin.  The  reason  that  the  flag  analysis 
can  reason  in  terms  of  abstract  sets  is  that  the  other  analyses  verify  that 
complex  data  structures  are  correctly  represented  using  sets. 

The  shape  analysis  plugin  enables  precise  verification  of  tree-based  data  struc¬ 
tures.  It  uses  a  previously  implemented  tool,  the  Pointer  Assertion  Logic  En¬ 
gine  [31]  (PALE).  We  have  incorporated  PALE  into  our  framework  with  essen¬ 
tially  no  changes  to  the  tool  itself 7 .  The  Hob  framework  effectively  enabled  the 
PALE  tool  to  be  applied  to  programs  to  which  it  was  previously  not  applicable 
due  to  both  scalability  reasons  and  the  limitations  of  the  PALE  programming 
model. 

To  verify  even  more  detailed  and  precise  data  structure  consistency  properties, 
we  implemented  a  theorem  proving  plugin  [38].  The  theorem  proving  plugin 
generates  verification  conditions  suitable  for  interactive  verification  using  the 
Isabelle  proof  assistant  [32] .  We  successfully  used  the  theorem  proving  plugin 
to  verify  array-based  data  structures  such  as  a  priority  queue  implemented  as 
a  binary  heap. 

8  Experience 

We  have  implemented  the  Hob  system,  populated  it  with  several  analyses 
(including  the  flag,  shape  analysis,  and  theorem  prover  plugins),  and  used 
the  system  to  develop  several  benchmark  programs  and  applications.  Fig¬ 
ure  12  presents  a  subset  of  the  benchmarks  we  ran  through  our  system; 
full  descriptions  of  our  benchmarks  (as  well  as  the  full  source  code  for  our 
modular  pluggable  analysis  system)  are  available  at  our  project  homepage  at 
http :  / /hob .  csail .  mit .  edu.  Minesweeper,  water  and  httpd  are  complete  ap¬ 
plications;  the  others  are  either  computational  patterns  (compiler,  scheduler, 
etas)  or  data  structures  (prodcons).  Compiler  models  a  constant-folding  com¬ 
piler  pass,  scheduler  models  an  operating  system  scheduler,  and  etas  models 


7  We  modified  PALE  to  indicate  success  or  failure  with  an  exit  code. 


18 


Number  of 

Lines 

Lines 

modules 

of  spec 

of  impl 

prodcons 

41 

50 

compiler 

86 

143 

scheduler 

37 

22 

etas 

53 

53 

board 

126 

222 

controller 

76 

155 

view 

57 

358 

minesweeper 

6 

367 

889 

atom 

31 

64 

ensemble 

164 

883 

li2o 

158 

423 

water 

10 

582 

1979 

sendfile 

32 

162 

httpserver 

20 

79 

littprequest 

49 

128 

httpd 

10 

246 

614 

Fig.  12.  Benchmark  characteristics 


the  core  of  an  air-traffic  control  system.  The  board,  controller,  and  view  mod¬ 
ules  are  the  core  minesweeper  modules;  atom,  ensemble,  and  h2o  are  the  core 
water  modules;  and  sendfile,  httpserver  and  littprequest  the  core  httpd  mod¬ 
ules.  The  bold  entries  indicate  system  totals  for  minesweeper  and  water;  note 
that  minesweeper  includes  several  other  modules,  some  of  which  are  analyzed 
by  the  shape  analysis  and  theorem  proving  plugins,  not  the  flag  plugin. 

We  next  present  the  impact  of  the  formula  transformation  optimizations, 
then  discuss  the  properties  that  we  were  able  to  specify  and  verify  in  the 
minesweeper  and  water  benchmarks. 

8. 1  Formula  Transformations 

We  analyzed  our  benchmarks  on  a  2.80GHz  Pentium  4,  running  Linux,  with 
3  gigabytes  of  RAM.  Figure  13  summarizes  the  results  of  our  formula  trans¬ 
formation  optimizations.  A  / in  the  “Optimizations”  column  indicates  a  run 
in  which  all  optimizations  are  enabled;  an  x  indicates  a  run  in  which  they  are 
disabled.  The  “Number  of  nodes”  column  reports  the  sizes  (in  terms  of  AST 
node  counts)  of  the  resulting  boolean  algebra  formulas.  Our  results  indicate 
that  the  formula  transformations  reduce  the  formula  size  by  3.5  to  greater 
than  80  times  (often  with  greater  reductions  for  larger  formulas);  the  Opti¬ 
mization  Ratio  column  presents  the  reduction  obtained  in  formula  size.  The 
“MONA  time”  column  presents  the  time  spent  in  the  MONA  decision  proce¬ 
dure  (up  to  87  seconds  after  optimization);  the  “Flag  time”  column  presents 
the  time  spent  in  the  flag  analysis,  excluding  the  decision  procedure  (up  to 
46  seconds  after  optimization).  Without  optimization,  MONA  could  not  suc¬ 
cessfully  check  the  formulas  for  the  compiler,  board,  view,  ensemble  and  h2o 
modules  because  of  an  out  of  memory  error. 


19 


8.2  Minesweeper 


We  next  illustrate  liow  our  approach  enables  the  verification  of  properties 
that  span  multiple  modules.  Our  minesweeper  implementation  has  several 
modules:  a  game  board  module  (which  represents  the  game  state),  a  controller 
module  (which  responds  to  user  input),  a  view  module  (which  produces  the 
game’s  output),  an  exposed  cell  module  (which  stores  the  exposed  cells  in  an 
array) ,  and  an  unexposed  cell  module  (which  stores  the  unexposed  cells  in  an 
instantiated  linked  list).  There  are  787  non- blank  lines  of  implementation  code 
in  the  6  implementation  modules  and  328  non-blank  lines  in  the  specification 
and  abstraction  modules. 

Minesweeper  uses  the  standard  model- view-controller  (MVC)  design  pattern 
[16] .  The  board  module  (which  stores  an  array  of  Cell  objects)  implements  the 
model  part  of  the  MVC  pattern.  Each  Cell  object  may  be  mined,  exposed 
or  marked.  The  board  module  represents  this  state  information  using  the 
isMined,  isExposed  and  isMarked  fields  of  Cell  objects.  At  an  abstract 
level,  the  sets  MarkedCells,  MinedCells,  ExposedCells,  UnexposedCells, 
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/ 

4528 

6.38 

0.69 

m mm 

X 

28904 

— 

3.20 

/in 

view 

/ 

19311 

N/A 

5.45 

1.48 

X 

N/A 

— 

N/A 

>  438.50 

atom 

/ 

28317 

20.65 

5.33 

0.74 

X 

584834 

— 

1017.09 

27.76 

ensemble 

/ 

668110 

N/A 

86.99 

46.05 

X 

N/A 

— 

N/A 

>  4070.00 

li2o 

/ 

79249 

>  15.87 

15.96 

25.70 

X 

>  1257883 

N/A 

N/A 

>  3282.08 

sendfile 

/ 

2672 

44.64 

0.87 

X 

119287 

— 

265.01 

5.26 

littpserver 

/ 

1094 

62.34 

0.21 

X 

68198 

— 

36.68 

5.75 

littprequest 

/ 

9521 

6.41 

0.67 

0.34 

X 

61041 

— 

12.589 

3.79 

Fig.  13.  Formula  sizes  before  and  after  transformation 
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and  U  (for  Universe)  represent  sets  of  cells  with  various  properties;  the  U  set 
contains  all  cells  known  to  the  board.  The  board  also  uses  a  global  boolean 
variable  gameOver,  which  it  sets  to  true  when  the  game  ends. 

Our  system  verifies  that  our  implementation  has  the  following  properties 
(among  others): 

•  The  sets  of  exposed  and  unexposed  cells  are  disjoint:  unless  the  game  is 
over,  the  sets  of  mined  and  exposed  cells  are  also  disjoint. 

•  The  set  of  unexposed  cells  maintained  in  the  board  module  is  identical  to 
the  set  of  unexposed  cells  maintained  in  the  Unexpo sedList  list. 

•  The  set  of  exposed  cells  maintained  in  the  board  module  is  identical  to  the 
set  of  exposed  cells  maintained  in  the  ExposedSet  array. 

•  At  the  end  of  the  game,  all  cells  are  revealed;  i.e.  the  set  of  unexposed  cells 
is  empty. 


Although  our  system  focuses  on  using  sets  to  model  program  state,  not  every 
module  needs  to  define  its  own  abstract  sets.  Indeed,  certain  modules  may  not 
define  any  abstract  sets  of  their  own,  but  instead  coordinate  the  activity  of 
other  modules  to  accomplish  tasks.  The  view  and  controller  modules  are 
examples  of  such  modules.  The  view  module  has  no  state  at  all;  it  queries 
the  board  for  the  current  game  state  and  calls  the  system  graphics  libraries 
to  display  the  state. 

Because  these  modules  coordinate  the  actions  of  other  modules — and  do  not 
encapsulate  any  data  structures  of  their  own — the  analysis  of  these  modules 
must  operate  solely  at  the  level  of  abstract  sets.  Our  analysis  is  capable  of 
ensuring  the  validity  of  these  modules,  since  it  can  track  abstract  set  member¬ 
ship,  solve  formulas  in  the  boolean  algebra  of  sets,  and  incorporate  the  effects 
of  invoked  procedures  as  it  analyzes  each  module.  Note  that  for  these  modules, 
our  analysis  need  not  reason  about  any  correspondence  between  concrete  data 
structure  representations  and  abstract  sets. 

The  set  abstraction  supports  typestate-style  reasoning  at  the  level  of  individ¬ 
ual  objects  (for  example,  all  objects  in  the  ExposedCells  set  can  be  viewed  as 
having  a  conceptual  typestate  Exposed) .  Our  system  also  supports  the  notion 
of  global  typestate.  The  board  module,  for  example,  has  a  global  gameOver 
variable  which  indicates  whether  or  not  the  game  is  over.  The  system  uses  this 
variable  and  the  definitions  of  relevant  sets  to  maintain  the  global  invariant 
gameOver  |  disjoint(MinedCells, ExposedCells). 

This  global  invariant  connects  a  global  typestate  property — is  the  game 
over? — with  a  object-based  typestate  state  property  evaluated  on  objects  in 
the  program — there  are  no  mined  cells  that  are  also  exposed.  Our  analysis 
plugins  verify  these  global  invariants  by  conjoining  them  to  the  preconditions 
and  postconditions  of  methods.  Note  that  global  invariants  must  be  true  in 
the  initial  state  of  the  program.  If  some  initializer  must  execute  to  establish 
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an  invariant,  then  the  invariant  can  be  guarded  by  a  global  typestate  variable. 

Another  invariant  concerns  the  correspondence  between  the  ExposedCells, 
UnexposedCells,  ExposedSet .Content,  and  UnexposedList .Content  sets: 

(ExposedCells  =  ExposedSet. Content)  &  (UnexposedCells  =  UnexposedList. Content) 


Our  analysis  verifies  this  property  by  conjoining  it  to  the  ensures  and 
requires  clauses  of  the  appropriate  procedures.  The  board  module  is  re¬ 
sponsible  for  maintaining  this  invariant.  Yet  the  analysis  of  the  board  mod¬ 
ule  does  not,  in  isolation,  have  the  ability  to  completely  verify  the  invari¬ 
ant:  it  cannot  reason  about  the  concrete  state  of  ExposedSet  .Content  or 
UnexposedList  .Content  (which  are  defined  in  other  modules).  However,  the 
ensures  clauses  of  its  callees,  in  combination  with  its  own  reasoning  that 
tracks  membership  in  the  ExposedCells  set,  enables  our  analysis  to  verify  the 
invariant  (assuming  that  ExposedSet  and  UnexposedList  work  correctly). 

Our  system  found  a  number  of  errors  during  the  development  and  maintenance 
of  our  minesweeper  implementation.  We  next  present  one  of  these  errors.  At 
the  end  of  the  game,  minesweeper  exposes  the  entire  game  board;  we  use 
removeFirst  to  remove  all  elements  from  the  unexposed  list,  one  at  a  time. 
After  we  have  exposed  the  entire  board,  we  can  guarantee  that  the  list  of 
unexposed  cells  is  empty: 

proc  drawFieldEndO 

requires  ExposedList . setlnit  &  Board. gameOver  & 

(UnexposedList. Content  <=  Board. U) 
modifies  UnexposedList .Content ,  Board. ExposedCells, 

Board . UnexposedCells ,  ExposedList . Content , 

UnexposedList . Content 
ensures  card (UnexposedList. Content1)  =  0; 

because  the  implementation  of  the  drawFieldEnd  procedure  loops 
until  isEmpty  returns  true,  which  also  guarantees  that  the 
UnexposedList  .Content  set  is  empty.  The  natural  way  to  write  the 
iteration  in  this  procedure  would  be: 

while  (UnexposedList. isEmptyO)  { 

Cell  c  =  UnexposedList. removeFirst () ; 
drawCellEnd(c) ; 

} 

and  indeed,  this  was  the  initial  implementation  of  that  code.  However,  when 
we  attempted  to  analyze  this  code,  we  got  the  following  error  message: 

Analyzing  proc  drawFieldEnd... 

Error  found  analyzing  procedure  drawFieldEnd: 

requires  clause  in  a  call  to  procedure  View.drawCellEnd. 


Upon  further  examination,  we  found  that  we  were  breaking  the  invariant 
Board. ExposedCells  =  UnexposedList . Content.  The  correct  way  to  preserve 
the  invariant  is  by  calling  Board .  setExposed,  which  simultaneously  sets  the 
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isExposed  flag  and  removes  the  cell  from  the  UnexposedList: 


Cell  c  =  UnexposedList  .getFirstO  ; 
Board. setExposed(c,  true); 
drawCellEnd(c) ; 


8.3  Water 

Water  is  a  port  of  the  Perfect  Club  benchmark  MDG  [2].  It  uses  a  predic¬ 
tor/corrector  method  to  evaluate  forces  and  potentials  in  a  system  of  water 
molecules  in  the  liquid  state.  The  central  loop  of  the  computation  performs  a 
time  step  simulation.  Each  step  predicts  the  state  of  the  simulation,  uses  the 
predicted  state  to  compute  the  forces  acting  on  each  molecule,  uses  the  com¬ 
puted  forces  to  correct  the  prediction  and  obtain  a  new  simulation  state,  then 
uses  the  new  simulation  state  to  compute  the  potential  and  kinetic  energy  of 
the  system. 

Water  consists  of  several  modules,  including  the  simparm,  atom,  H20, 
ensemble,  and  main  modules.  These  modules  contain  2000  lines  of  implemen¬ 
tation  and  500  lines  of  specification.  Each  module  defines  sets  and  boolean 
variables;  we  use  these  sets  and  variables  to  express  safety  properties  about 
the  computation. 

The  simparm  module,  for  instance,  is  responsible  for  recording  simulation  pa¬ 
rameters,  which  are  stored  in  a  text  file  and  loaded  at  the  start  of  the  compu¬ 
tation.  This  module  defines  two  boolean  variables,  Init  and  ParmsLoaded.  If 
Init  is  true,  then  the  module  has  been  initialized,  i.e.  the  appropriate  arrays 
have  been  allocated  on  the  heap.  If  ParmsLoaded  is  true,  then  the  simulation 
parameters  have  been  loaded  from  disk  and  written  into  these  arrays.  Our 
analysis  verifies  that  the  program  does  not  load  simulation  parameters  until 
the  arrays  have  been  allocated  and  does  not  read  simulation  parameters  until 
they  have  been  loaded  from  the  disk  and  written  into  the  arrays. 

The  fundamental  unit  of  the  simulation  is  the  atom,  which  is  encapsulated 
within  the  atom  module.  Atoms  cycle  between  the  predicted  and  corrected 
states,  with  the  predic  and  correc  procedures  performing  the  computations 
necessary  to  effect  these  state  changes.  A  correct  computation  will  only  predict 
a  corrected  atom  or  correct  a  predicted  atom.  To  enforce  this  property,  we 
define  two  sets  Predic  and  Correc  and  populate  them  with  the  predicted 
and  corrected  atoms,  respectively.  The  correc  procedure  operates  on  a  single 
atom;  its  precondition  requires  this  atom  to  be  a  member  of  the  Predic  set.  Its 
postcondition  ensures  that,  after  successful  completion,  the  atom  is  no  longer 
in  the  Predic  set,  but  is  instead  in  the  Correc  set.  The  predic  procedure  has 
a  corresponding  symmetric  specification. 

Atoms  belong  to  molecules,  which  are  handled  by  the  H20  module.  A  molecule 
tracks  the  position  and  velocity  of  its  three  atoms.  Like  atoms,  each  module 
can  be  in  a  variety  of  conceptual  states.  These  states  indicate  not  only  whether 
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the  program  has  predicted  or  corrected  the  position  of  the  molecule’s  atoms 
but  also  whether  the  program  has  applied  the  intra-molecule  force  corrections, 
whether  it  has  scaled  the  forces  acting  on  the  molecule,  etc.  We  verify  the 
invariant  that  when  the  molecule  is  in  the  predicted  or  corrected  state,  the 
atoms  in  the  molecule  are  also  in  the  same  state.  The  interface  of  the  H20 
module  ensures  that  the  program  performs  the  operations  on  each  molecule 
in  the  correct  order  —  for  example,  the  bndry  procedure  may  operate  only  on 
molecules  in  the  Kineti  set  (which  have  had  their  kinetic  energy  calculated 
by  the  kineti  procedure). 

The  ensemble  module  manages  the  collection  of  molecule  objects.  This  module 
stages  the  entire  simulation  by  iterating  over  all  molecules  and  computing 
their  positions  and  velocities  over  time.  The  ensemble  module  uses  boolean 
predicates  to  track  the  state  of  the  computation.  When  the  boolean  predicate 
INTERF  is  true,  for  example,  then  the  program  has  completed  the  interforce 
computation  for  all  molecules  in  the  simulation.  Our  analysis  verifies  that  the 
boolean  predicates,  representing  program  state,  satisfy  the  following  ordering 
relationship: 

Init  INITIA  ^  PREDIC  INTRAF  VIR  ^  INTERF  . . . 


Our  specification  relies  on  an  implication  from  boolean  predicates  to  properties 
ranging  over  the  collection  of  molecule  objects,  which  can  be  ensured  by  a 
separate  array  analysis  plugin  [24]. 

These  properties  help  ensure  that  the  computation’s  phases  execute  in  the  cor¬ 
rect  order;  they  are  especially  valuable  in  the  maintenance  phase  of  a  program’s 
life,  when  the  original  designer,  if  available,  may  have  long  since  forgotten  the 
program’s  phase  ordering  constraints.  Our  analysis’  set  cardinality  constraints 
also  prevent  empty  sets  (and  null  pointers)  from  being  passed  to  procedures 
that  expect  non-empty  sets  or  non-null  pointers. 


9  Related  Work 

In  this  section  we  discuss  related  work  in  the  general  area  of  program  checking 
tools  and  other  typestate  systems  in  particular.  We  start  by  comparing  the 
1 1  of)  framework  to  the  approach  taken  by  the  ESC/ Java  and  Boogie  program 
checking  tools;  next,  we  discuss  general  properties  of  typestate  systems  and 
compare  Hob’s  sets  to  typestate  systems. 

Program  checking  tools.  ESC/ Java  [14]  is  a  program  checking  tool  whose 
purpose  is  to  identify  common  errors  in  programs  using  program  specifications 
in  a  subset  of  the  Java  Modelling  Language  (JML)  [3].  ESC/ Java  sacrifices 
soundness  in  that  it  does  not  model  all  details  of  the  program  heap,  but  can 
detect  some  common  programming  errors.  The  Spec#  programming  system  [1] 
adds  similar  features  to  C#,  including  the  ability  to  specify  method  contracts, 
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frame  conditions  and  class  contracts.  These  contracts  may  be  verified  at  run¬ 
time  or  by  the  Boogie  static  verifier,  which  uses  a  theorem  prover  to  discharge 
its  verification  conditions. 

We  discuss  two  key  differences  between  our  approach  and  the  proposed  Boogie 
approach.  First,  Boogie  envisions  the  use  of  a  single  general-purpose  theorem 
prover  to  discharge  the  generated  verification  conditions.  Hob,  on  the  other 
hand,  is  designed  to  support  a  diverse  range  of  potentially  narrow,  specialized 
analyses  (this  range  includes  shape  analyses,  typestate  analyses  [26]  and  even 
interactive  theorem  provers  [38]  as  well  as  less  detailed  analyses).  This  goal 
is  reflected  in  Hob’s  format  construct  and  in  its  abstract  set  specification 
language,  both  of  which  are  designed  to  support  a  strong  separation  between 
different  analyses  (such  a  separation  is  necessary,  of  course,  if  multiple  analyses 
are  to  cooperate  to  successfully  analyze  a  single  program).  This  approach 
minimizes  the  amount  of  expertise  required  to  work  within  the  Hob  system 
and  maximizes  the  ability  of  developers  with  specialized  skills  to  contribute. 
We  believe  that  enabling  as  many  developers  to  contribute  as  possible  will 
lead  to  a  richer,  more  powerful  analysis  system. 

Second,  Boogie  is  designed  to  verify  object  invariants,  with  an  object  own¬ 
ership  mechanism  supporting  the  hierarchical  specification  and  verification  of 
invariants  that  involve  hierarchies  of  linked  objects.  This  mechanism  eliminates 
a  form  of  specification  aggregation  for  computations  that  traverse  a  hierarchy 
of  owned  objects — if  the  procedure  call  hierarchy  matches  the  ownership  hier¬ 
archy,  each  procedure  need  only  state  consistency  requirements  for  the  object 
that  it  directly  accesses,  not  all  of  the  child  objects  that  that  object  owns.  This 
hierarchical  specification  approach  is  reminiscent  of  hierarchical  access  speci¬ 
fications  in  Jade  [33]  and  hierarchical  locking  mechanisms  in  databases  [36]. 

Hob,  on  the  other  hand,  is  designed  to  support  computations  organized  around 
a  flat  set  of  data  structures.  The  constructs  that  eliminate  specification  aggre¬ 
gation  cut  across  the  procedure  call  hierarchy  rather  than  working  within  it. 
This  adoption  of  cross-cutting  organizational  approaches  reflects  the  matura¬ 
tion  of  computer  science  as  a  discipline — over  time,  the  overwhelming  domi¬ 
nance  of  hierarchical  approaches  will  fade  as  the  effectiveness  of  using  other 
approaches  in  addition  to  hierarchies  becomes  obvious. 

Typestate  systems.  Typestate  systems  track  the  conceptual  states  that 
each  object  goes  through  during  its  lifetime  in  the  computation  [7,9-12,37]. 
They  generalize  standard  type  systems  in  that  the  typestate  of  an  object 
may  change  during  the  computation.  Aliasing  (or  more  generally,  any  kind  of 
sharing)  is  the  key  problem  for  typestate  systems — if  the  program  uses  one 
reference  to  change  the  typestate  of  an  object,  the  typestate  system  must 
ensure  that  either  the  declared  typestate  of  the  other  references  is  updated  to 
reflect  the  new  typestate  or  that  the  new  typestate  is  compatible  with  the  old 
declared  typestate  at  the  other  references. 
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Most  typestate  systems  avoid  this  problem  altogether  by  eliminating  the  pos¬ 
sibility  of  aliasing  [37].  Generalizations  support  monotonic  typestate  changes 
(which  ensure  that  the  new  typestate  remains  compatible  with  all  existing 
aliases)  [12]  and  enable  the  program  to  temporarily  prevent  the  program 
from  using  a  set  of  potential  aliases,  change  the  typestate  of  an  object  with 
aliases  only  in  that  set,  then  restore  the  typestate  and  reenable  the  use  of 
the  aliases  [10].  It  is  also  possible  to  support  object-oriented  constructs  such 
as  inheritance  [8].  Finally,  in  the  role  system,  the  declared  typestate  of  each 
object  characterizes  all  of  the  references  to  the  object,  which  enables  the  type- 
state  system  to  check  that  the  new  typestate  is  compatible  with  all  remaining 
aliases  after  a  nonmonotonic  typestate  change  [21], 

In  our  approach,  the  typestate  of  each  object  is  determined  by  its  member¬ 
ship  in  abstract  sets  as  determined  by  the  values  of  its  encapsulated  fields 
and  its  participation  in  encapsulated  data  structures.  Our  system  supports 
generalizations  of  the  standard  typestate  approach  such  as  orthogonal  types¬ 
tate  composition  and  hierarchical  typestate  classification.  The  connection  with 
data  structure  participation  enables  the  verification  of  both  local  and  global 
data  structure  consistency  properties. 


10  Conclusion 

Typestate  systems  have  traditionally  been  designed  to  enforce  safety  condi¬ 
tions  that  involve  objects  whose  state  may  change  during  the  course  of  the 
computation.  In  particular,  the  standard  goal  of  typestate  systems  is  to  en¬ 
sure  that  operations  are  invoked  only  on  objects  that  are  in  appropriate  states. 
Most  existing  typestate  systems  support  a  flat  set  of  object  states  and  limit 
typestate  changes  in  the  presence  of  sharing  caused  by  aliasing.  We  have  pre¬ 
sented  a  reformulation  of  typestate  systems  in  which  the  typestate  of  each 
object  is  determined  by  its  membership  in  abstract  typestate  sets.  This  refor¬ 
mulation  supports  important  generalizations  of  the  typestate  concept  such  as 
typestates  that  capture  membership  in  data  structures,  composite  typestates 
in  which  objects  are  members  of  multiple  typestate  sets,  hierarchical  types¬ 
tates,  and  cardinality  constraints  on  the  number  of  objects  that  are  in  a  given 
typestate.  In  the  context  of  our  Hob  modular  pluggable  analysis  framework, 
our  system  also  enables  the  specification  and  effective  verification  of  detailed 
local  and  global  data  structure  consistency  properties,  including  arbitrary  in¬ 
ternal  consistency  properties  of  linked  and  array-based  data  structures.  Our 
system  therefore  effectively  supports  tasks  such  as  understanding  the  global 
sharing  patterns  in  large  programs,  verifying  the  absence  of  undesirable  inter¬ 
actions,  and  ensuring  the  preservation  of  critical  properties  necessary  for  the 
correct  operation  of  the  program. 
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A  Transfer  Functions 


This  section  presents  the  transfer  functions  for  the  flag  analysis. 


Assignment  statements.  We  first  define  a  generic  frame  condition  genera¬ 
tor,  used  in  our  transfer  functions, 

frame*  =  f\  S'  -  S  A  /\  (//  <  >  p). 

Sfi^x,  S  not  derived  pfix 

where  S  ranges  over  sets  and  p  over  boolean  predicates.  Note  that  derived 
sets  are  not  preserved  by  frame  conditions;  instead,  the  analysis  preserves  the 
anonymous  sets  contained  in  the  derived  set  definitions  and  conjoins  these 
definitions  to  formulas  before  applying  the  decision  procedure. 


Our  flag  analysis  also  tracks  values  of  boolean  variables: 


(F( b  =  true)  =  t/  A  frames 
(F( b  =  false)  =  (-it/)  A  frames 
(F( b  =  y)  =  (b7  4A  y)  A  frames 
(F( b  =  (if  cond))  =  (t/  4A  /+(( if  cond)))  A  frames 

T{ b  =!e)  =  iF(b  =  e)  o  ((b7  4=>  ->b)  A  frame&) 


where  /+(e)  is  the  result  of  evaluating  e,  defined  below  in  our  analysis  of 
conditionals. 


The  analysis  also  track  local  variable  object  references: 

/F(x  =  y)  =  (x7  =  y)  A  frame*  /F(x  =  null)  =  (x7  =  0)  A  frame* 
T(x  =  new  t)  =  -i(x7  =  0)  A  /\s(x7  n  S  =  0)  A  frame* 
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We  next  present  the  transfer  function  for  changing  set  membership.  If  R  — 

{x  :  T  |  x.f  =  c}  is  a  set  definition  in  the  abstraction  section,  we  have: 

^•(x.f  =  c)  =  R'  =  RU  x  A  Aseaits(ii)  S' =  S\x  A  frame{fl}u  ahs(Ji) 

where  alts(R)  =  {S  |  abstraction  module  contains  S  —  {x  :T  \  x.f  —  ci},  c\  A  c.} 

The  rules  for  reads  and  writes  of  boolean  fields  are  similar  but,  because  our 
analysis  tracks  the  flow  of  boolean  values,  more  detailed: 

T(  .  _  (bAB+'  =  B+Ux  \  (~<b  A  B~' =  B~Ux 

[  ~b)~{  A  Asealts(B+)  S' =  S\x)A{  A  AseaitsCB-)  S’  «  5  \  X 

Aframe{s}Ua|ts(B) 

.F(b  =  y.f )  =  (b1  AA  y  €  B+)  A  frame;,. 

where  B+  =  {x  :  T  \  x.f  =  true}  and  B~  —  {x  :  T  \  x.f  =  false}. 

Finally,  we  have  some  default  rules  to  conservatively  account  for  expressions 
not  otherwise  handled. 

T{x.f  =  *)  =  framex  =  *)  =  framex. 

Procedure  calls.  For  a  procedure  call  x=proc  (y) ,  our  transfer  function 
checks  that  the  callee’s  requires  condition  holds,  then  incorporates  proc’s  en¬ 
sures  condition  as  follows: 

jF(x  =  proc(y))  =  ensuresi(proc)  A  f\ S'  i=  S 

s 

where  both  ensuresi  and  requiresL  substitute  caller  actuals  for  formals  of  proc 
(including  the  return  value),  and  where  S  ranges  over  all  local  variables. 


Conditionals.  The  analysis  produces  a  different  formula  for  each  branch 
of  an  if  statement  if  (e).  We  define  functions  /+(e),/_(e)  to  summarize 
the  additional  information  available  on  each  branch  of  the  conditional;  the 
transfer  functions  for  the  true  and  false  branches  of  the  conditional  are  thus, 
respectively, 


[if  (e)]+(£)  =  f+(e)AB  [if  (e)j~(B)  =  f~{e)  A  B. 


For  constants  and  logical  operations,  we  define  the  obvious  /+,  /  : 


/+(true)  =  true 
/+(false)  =  false 

/+(!e)  =  /-(e) 
f+(x\=e)  =  /  (x==e) 

/+(e  1  &&  e2)  =  /+(ei)  A  /+(e2) 


/  (true)  =  false 
/-(false)  =  true 

/-(!e)  =  /+(e) 

/  (x !  =e)  =  f+(x==e ) 

/-(e  1  &&  e2)  =  /“(el)  V  f~(e2 ) 


We  define  /+,  /  for  boolean  fields  as  follows: 

f+(x.f )  x  C  B  f~(x.f)  =  x  %  B 

f+(x.f=- false)  =  x  ^  B  f~(x.f== false)  =  x  Q  B 
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where  B  —  {x  \T  \  x.f  =  true};  analogously,  let  R  =  {x  :  T  \  x.f  —  c}.  Then, 
./'  •  (x.f==c)  =  xQR  f~(x.f== c)  =  x  %  R. 

We  also  predicate  the  analysis  on  whether  a  reference  is  null  or  not: 

f+(x== null)  =  x  =  0  /_(r==null)  =  x  ^  0. 

Finally,  we  have  a  catch-all  condition, 

/+(*)  =  true  f~i *)  =  true 

which  conservatively  captures  the  effect  of  unknown  conditions. 

Assertions  and  Assume  Statements.  We  analyze  statement  s  of  the  form 
assert  A  by  showing  that  the  formula  for  the  program  point  s  implies  A. 
Assertions  allow  developers  to  check  that  a  given  set-based  property  holds  at 
an  intermediate  point  of  a  procedure.  Using  assume  statements,  we  allow  the 
developer  to  specify  properties  that  are  known  to  be  true,  but  which  have  not 
been  shown  to  hold  by  this  analysis.  Our  analysis  prints  out  a  warning  mes¬ 
sage  when  it  processes  assume  statements,  and  conjoins  the  assumption  to  the 
current  dataflow  fact.  Assume  statements  have  proven  to  be  valuable  in  under¬ 
standing  analysis  outcomes  during  the  debugging  of  procedure  specifications 
and  implementations.  Assume  statements  may  also  be  used  to  communicate 
properties  of  the  implementation  that  go  beyond  the  abstract  representation 
used  by  the  analysis. 

Return  Statements.  Our  analysis  processes  the  statement  return  x  as  an 
assignment  rv  =  x.  where  rv  is  the  name  given  to  the  return  value  in  the 
procedure  declaration.  For  all  return  statements  (whether  or  not  a  value  is 
returned),  our  analysis  checks  that  the  current  formula  implies  the  procedure’s 
postcondition  and  stops  propagating  that  formula  through  the  procedure. 
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